Summary Prophet is a forecasting method from Meta’s Core Data Science team. It works well for business numbers that follow repeating patterns, such as retail sales, website traffic, and revenue. This blog explains where Prophet helps, why it is easy to understand and use, and when it needs extra care. Table of Contents 01 Introduction 02 Retail Sales Forecasting: Planning for Demand 03 Forecasting Website Traffic and Infrastructure Needs 04 Forecasting Business Numbers: Growth and Operational Trends 05 Why Use Prophet? 06 When Prophet May Not Fit Well 07 Making Forecasts Useful for the Business 08 FAQs 09 Conclusion Introduction Every organization generates data. Sales, customer activity, website traffic, daily operations, and system usage all build up a history over time. The value of this data is not only in understanding what happened yesterday. It is also in preparing for what may happen next and making better decisions today. This is where forecasting is useful for business leaders. Prophet, developed by Meta’s Core Data Science team, is a practical way to forecast business numbers that follow repeating patterns, seasonal changes, and changing growth. However, Prophet is not suitable for every forecasting problem. How well it works depends on the business problem, the past data available, and the decisions the forecast will support. Where Prophet Can Help 1 Retail Sales Plan stock, purchasing and delivery around weekly, seasonal and holiday patterns. 2 Website Traffic Forecast visits and usage to plan how much system capacity is needed. 3 Business Numbers Forecast revenue, new customers and user growth for planning. 1. Retail Sales Forecasting: Planning for Demand Retail demand changes throughout the year. Sales are affected by weekly shopping habits, seasons, promotions, and holidays. These patterns directly affect inventory, purchasing, delivery planning, and revenue expectations. A 2020 research study, Application of Facebook’s Prophet Algorithm for Successful Sales Forecasting Based on Real-world Data, used Prophet on actual sales data from a large retail company in Bosnia and Herzegovina. The study showed how Prophet, together with testing on past data, can be used to forecast retail sales and check how reliable the forecast is for different products. Why Prophet Makes Sense Seasonal patterns: Retail sales often rise and fall on weekly and yearly cycles, and Prophet can include these. Holidays: Known holidays and special events can be added to the forecast. Changing trends: The forecast can allow sales trends to change instead of assuming steady growth. Many products: The same approach can be used for many products. The reliability of each product’s forecast should be checked separately. The goal is not only to predict sales. It is to help the business make better decisions about stock availability, purchasing schedules, delivery planning, and cash planning. A forecast is useful when it connects directly to a business decision. 2. Forecasting Website Traffic and Infrastructure Needs Websites and online platforms produce operational data all the time. Website visits, app usage, and system load often follow patterns based on weekdays, weekends, seasons, and business events. Meta’s original work on Prophet aimed to make business forecasting easier to use at a larger scale, including forecasting the numbers used to plan how much system capacity is needed. One example is using past website traffic to forecast future demand. The aim is to understand how traffic is likely to change and whether the current infrastructure can support it. Why Prophet Makes Sense More than one pattern: Daily traffic can follow both weekly and yearly patterns. Changing growth: Growth can change as products change or more people start using them. Capacity planning: Forecasts help infrastructure teams plan for future needs. Spotting differences: Forecasts can be compared with actual traffic to notice unexpected changes. For leaders, the benefit is linking the forecast to infrastructure spending decisions. Instead of relying only on past peak usage or reacting once demand rises, teams can use forecast demand as one more input when planning capacity. This is helpful when cost, system performance, and customer experience all need to be balanced. 3. Forecasting Business Numbers: Growth and Operational Trends Organizations regularly track numbers such as revenue, new customers, user activity, and operational volumes. Prophet was designed to support business forecasting at larger scale, including numbers such as revenue and user growth. These numbers often show repeating patterns, an overall growth trend, and changes caused by business events. Why Prophet Makes Sense Easy to understand: The trend and seasonal parts of the forecast make it easier to read and explain. Changing growth: It can handle growth that speeds up or slows down over time. Known business events: Events such as product launches can be included when their effect is described properly. Easy to review: Business teams can look at the trend and seasonal parts instead of receiving only a final number. This is useful when forecasts need to be reviewed and understood by finance, operations, and leadership, and not only by the data team. The forecast can support revenue planning, growth estimates, resource allocation, and operational reviews. One thing to keep in mind: a forecast of a business number does not explain why that number is changing. Understanding the effect of pricing, marketing campaigns, customer behavior, or other business factors may need additional analysis. Why Use Prophet? Prophet builds a forecast from parts of the past data: the trend, the seasonal patterns, and the effect of holidays and events. These parts reflect patterns that are common in business data, and they do not require a lot of manual setup. What Prophet Looks At The parts of past data that shape a Prophet forecast 1 Trend The general direction of the numbers over time. 2 Weekly patterns M T W T F S S Repeating changes across the days of the week. 3 Yearly patterns Jan Dec Repeating changes across the seasons of the year. 4 Holidays and events Known dates, such as holidays or product launches, that affect the numbers. From Past Data to a Business Decision 1 Past Business Data Sales, traffic, revenue or other numbers. 2 Prophet … Continue reading Forecasting with Prophet-When Does It Make Sense →

Correcting Receipt Costs Before Inventory Closing in Dynamics 365 Finance & Operations Summary Inventory closing in Dynamics 365 Finance & Operations settles issues against receipts. If a receipt carries the wrong cost, closing pushes that error into cost of goods sold and closing stock value. The client is a multi-country oil & gas and marine services provider, serving exploration and production operators from offices across the Middle East and Asia. They run Dynamics 365 Finance & Supply Chain Management for accounting, procurement, project management and inventory, with Power BI on top for reporting. During a month-end support engagement we found one receipt valued at a fraction of an identical earlier receipt. We corrected it through a transaction adjustment, recalculated the item, checked ageing and only then ran closing. The fix itself takes minutes. The order of the steps is what matters. Table of Contents 1. Business Challenges 2. Solution Overview 3. Approach & Methodology 4. Impact 5. FAQs 1. Business Challenges We found two receipts of the same item, at the same site and warehouse, for the same quantity of 5. Their values were far apart. Receipt Quantity Posted value Value per unit Receipt 1 5 23,050.15 4,610.03 Receipt 2 5 1,375.00 275.00 Same item, same site and warehouse, same quantity. If we had run closing on these values, two things would have happened. Every issue settled against the second receipt would have been settled at too low a cost, understating cost of goods sold. Inventory value at month-end would have been understated. 2. Solution Overview Closing uses the cost on each receipt to settle and adjust issues. When we correct the receipt first and then recalculate, D365 re-costs the dependent issues for us. Correcting after closing is more work. It means reversing the close or posting further adjustments in a later period. The sequence we follow: Correct the cost, recalculate the item, check ageing, then close. 1 Correct cost Transaction adjustment 2 Recalculate Re-costs dependent issues 3 Check ageing Confirm values flow through 4 Close Run on correct values Fix the receipt before anything settles against it. Reversing this order later means a reopened period. The correction sequence: cost first, then recalculation, then an ageing check, and only then closing. Reverse that order and a quick fix becomes a reopened period. 3. Approach & Methodology 1. Correct the item cost through a transaction adjustment Go to Inventory management > Periodic tasks > Closing and adjustment. Open a transaction adjustment. On the action pane, select Adjustment > Transactions. An adjustment voucher opens, dated the month-end. Choose the transactions. Select Select to choose the transactions to adjust. Filter by item. In the query, enter the item number in Criteria against the Item number field. Add other ranges such as financial date if needed, then select OK. Enter the correct unit cost. The item’s open receipts load with posted quantity and posted value. Select Adjustment > Item cost price and enter the correct unit cost. The Adjustment column shows the change per line. Post. Select Post. Recalculate the item. Run an item-wise Recalculation from Closing and adjustment, dated the month-end, so dependent issues pick up the corrected cost. Inventory management  ›  Periodic tasks  ›  Closing and adjustment Adjustment ▾Close procedure ▾RecalculationInquiries AdjustmentTransactions Voucher dateMonth-end Adjust transactions, query filtered by item number Receipt Posted qty Posted value Item cost price Adjustment Receipt 1 5 23,050.15 4,610.03 No change Receipt 2 5 1,375.00 4,610.03 +21,675.15 Posted, ready for recalculation Illustrative mockup of the Closing and adjustment / Adjust transactions flow, not an actual product screenshot. The item cost price adjustment lands on the under-valued receipt line and shows the resulting adjustment amount. 2. Check inventory ageing Review the inventory ageing report as on the month-end date. Confirm the corrected values flow through. Inventory management  ›  Inquiries and reports  ›  Inventory ageing CalculateExport ▾PrintInquiries As of dateMonth-end Item numberFiltered Inventory ageing by value as on the month-end date Item Qty on hand 0–30 days 31–60 days 61–90 days Total value Item (same item) 10 46,100.30 0.00 0.00 46,100.30 Corrected value flows through, both receipts now aligned Illustrative mockup of the Inventory ageing inquiry, not an actual product screenshot. After the adjustment and recalculation, the second receipt’s value lines up with the first and total inventory value is correct. 3. Run inventory closing In Closing and adjustment, select Close procedure > Close, set the month-end date and run it. Confirm the new closing line shows OK, and review the log if it has warnings. Inventory management  ›  Periodic tasks  ›  Closing and adjustment Close procedure ▾Adjustment ▾RecalculationInquiries Closing nameMonth-end close Closing dateMonth-end Close procedure > Close: closing run history Closing Closing date Run type Status Prior period Previous month-end Closing Closed Month-end close Month-end Closing Closed OK Closing completed with no errors in the log Illustrative mockup of Close procedure > Close, not an actual product screenshot. The closing run completes with status OK once it runs on the corrected receipt values. 4. Impact Before Correct after closing Issues settled at too low a cost flow into cost of goods sold Month-end inventory value is understated Fix needs a close reversal or later-period adjustments Rework in the next period After Correct before closing Receipt cost fixed through a transaction adjustment Recalculation re-costs dependent issues automatically Closing runs on correct receipt values Minutes of checks before close Practical takeaway Make a receipt-cost check part of your pre-closing routine. Look for receipts of the same item whose value per unit is far out of line with earlier receipts. Correct them through a transaction adjustment, recalculate, then close. 5. FAQs 1. Why not just correct the cost after closing? Because closing has already settled issues against the wrong receipt cost. Fixing it afterwards means either reversing the close or posting further adjustments in a later period. Both take far more work than a check before you close. 2. What does recalculation do that closing does not? Recalculation re-costs the dependent issues using the corrected receipt cost without finalising … Continue reading How a Multi-Country Oil & Gas and Marine Services Provider Corrected Receipt Costs Before Inventory Closing in Dynamics 365 Finance & Operations →

Summary Our client is a US-based manufacturer of premium connected countertop cooking appliances, sold direct to consumers and through retail partners. Their in-house support team works warranty, returns and device troubleshooting cases in Dynamics 365, but the rules for handling those cases lived outside it, in documents that had to be opened in a second tab. We built what they call the troubleshoot guide using the side pane, a part of the app shell most implementations never touch because the out of the box app only uses it for the productivity pane and the Copilot panel. A Quick Reference Guide icon in the right-hand rail opens a business rules library beside the record, it stays open while the agent moves from one case to the next, and it is edited in place by the people who own the rules. The content sits in Dataverse rows instead of in a solution, so adding or correcting a rule is a data change rather than a deployment. This post covers why we chose that surface, the two design calls we reversed mid build, and the limits we would design around on a second pass. ⓘPart of a wider engagement The troubleshoot guide is one piece of a longer programme of Dynamics 365 enhancements, reporting and third-party integrations for this client. Read the full Customer Success Story. Table of Contents Summary→ Business Challenges→ Solution Overview→ Technical Approach→ Impact→ Conclusion→ Let’s Talk→ Business Challenges The problem was never that the rules did not exist. The problem was where they sat relative to the work. The handling rules lived in documents outside CRM, so finding the right paragraph meant leaving the case form and giving up the record context Rules changed more often than anyone could republish them, and a correction had to go back through whoever owned the file Nothing tied a rule to the moment it was needed. The agent already had the case open and still had to remember which policy applied Anything that put the content on a form tab would have turned a typo fix into a customisation, an export and an import ⚠The cost was the switch, not the search Opening a document is quick. Rebuilding where you were in a case after you come back is not, and that happened on every lookup. Solution Overview The troubleshoot guide is a side pane. Most users only ever meet that surface as the productivity pane in Customer Service, and most project teams reach for a dialog or a form tab because those are the shapes everyone already knows. The pane is the only one of the three that keeps the reference material and the record on screen together. The entry point is a Quick Reference Guide icon in the right-hand rail of the app. It is there as soon as a case is opened and on a case the agent is still creating, so somebody taking a call does not have to save the record first. The launcher sits in the right rail, available on an open case and on a new one. One click opens the pane, and it stays pinned as the agent moves to the next record. Content is organised in two levels: a business rule heading, and sub-sections under it, all collapsed when the pane first renders so the agent sees the index before the detail. The pane in the right column of the app shell, beside the live form. What the pane does Two level structure. A business rule heading holds any number of sub-sections. Everything renders collapsed, so the agent reads an index first and opens only the rule they need Search across both levels. One box matches heading names and the body text of every sub-section at the same time, and auto-expands whatever it hits. Clearing the box restores exactly which sections were open before the search started Inline authoring. Add a heading, add a sub-section, write bold text, colour a warning line, insert a link. No second screen and no admin rights Insert images two ways. Upload from the device, or point at an existing URL. Either way the image is resized and compressed before it is stored Paste from Word and Outlook. The rule owners draft in Word. Pasted formatting is cleaned on the way in, and a screenshot sitting in the clipboard is embedded as part of the same paste Sort by dragging. Headings reorder against each other, sub-sections reorder within their heading, and the new position is saved the moment the item is dropped Move a sub-section to a different heading. Drag it out of one section and onto another. A collapsed heading opens itself when the item hovers over it, so nothing has to be expanded first Light and dark themes. A toggle in the pane header, remembered per browser, because the pane is open all day beside a form whose theme the agent does not control Delete that deactivates. Removing a heading deactivates its sub-sections first, then the heading, so nothing is orphaned and nothing is destroyed ⓘNothing here is a customisation Every heading and every sub-section is a Dataverse row. Publishing a new rule does not touch the solution and does not need a developer. Technical Approach Why the side pane and not a form tab We looked at three places to put the guide before writing anything. The deciding criterion was not how it looked, it was what survives the agent moving to the next record. Criteria Form tab Custom page dialog Our choiceSide pane Readable at the same time as the case fields partial ✗ ✓ Survives navigating to the next case ✗ ✗ ✓ Width the agent can drag to suit their screen ✗ ✗ ✓ Keeps scroll position and open sections between records ✗ ✗ ✓ No change to the form layout to adopt it ✗ ✓ ✓ The side pane has been available in the Dynamics 365 app shell since 2021 and almost nothing in the standard app uses it beyond … Continue reading How to Extend Dynamics 365 CRM Using Side Panes: A Practical Implementation for a US-Based Kitchen Appliance Manufacturer →

Sending Dynamics 365 Emails from JavaScript with the Dataverse Web API | CloudFronts Summary Most Dynamics 365 emails are generated by workflows, Power Automate flows, or plugins reacting to a record change. But some notifications are triggered by a user action inside a custom UI, where the browser already holds all the context and the user needs to know immediately whether the email went out. In this implementation, we generated and sent Dynamics 365 email activities directly from JavaScript running in an HTML web resource, using only the Dataverse Web API. The email is created with sender and recipient activity parties, linked to a related record through the Regarding lookup, and sent through the SendEmail bound action for delivery by server-side synchronization. This article covers the problem, the use case, how an email is structured in Dataverse, and a step-by-step walkthrough of the JavaScript implementation, including the pitfalls we hit along the way. Table of Contents Problem Statement The Use Case Why Send Emails from JavaScript? Anatomy of an Email in Dataverse Solution Overview Step 1 — A Reusable Web API Helper Step 2 — Identifying the Sender Step 3 — Resolving the Recipient Dynamically Step 4 — Creating the Record the Email Will Be Regarding Step 5 — Composing the Subject and HTML Body Step 6 — Building the Activity Parties Step 7 — Binding the Regarding Lookup Step 8 — Creating the Email Record Step 9 — Sending the Email with SendEmail Understanding the Email Lifecycle The Complete Email Function Error Handling Testing and Validation Security and Production Considerations Key Implementation Lessons Conclusion Frequently Asked Questions This Blog Explains When a user action, rather than a record change, should be the trigger for an email. How an email activity, its activity parties, and its Regarding lookup fit together in Dataverse. How to create an email with From and To recipients through the Web API. The Regarding navigation property naming that commonly causes silent failures. The difference between creating an email and sending it. Why sent emails show as Pending Send, and what has to be configured for delivery. Read more about our Journey with this Customer over here: View Case Study  |  Refer my previous blog on the associated topic for more context Problem Statement Dynamics 365 offers several ways to send email automatically, and nearly all of them are record-driven: something is created or updated, and a workflow, flow, or plugin reacts to it. That model breaks down when the event worth notifying about is not a simple record change but an action a user performs in a custom interface, such as an HTML web resource or a custom page. In those cases: The trigger is a button click, and the relevant context (who acted, what changed, what the previous value was) lives in the browser. The email must only be sent once a multi-step operation has fully succeeded, not when it starts. The user expects immediate confirmation that the notification went out, or a clear message if it did not. The email should be a proper Dynamics 365 activity, visible on a related record’s timeline, not an untracked message sent from outside CRM. An asynchronous flow cannot give the user that immediate feedback, and a plugin would need to reconstruct context the UI already has. The question became: Can we create, link, and send a fully tracked Dynamics 365 email directly from the JavaScript that handles the user’s action, using only the Dataverse Web API? The Use Case The scenario was a custom Dataverse Choice (Option Set) Manager, an HTML web resource that lets authorized users add or relabel picklist values (for example, Lead Source) from within Dynamics 365.Building Self-Service Dataverse Choice Picklist values feed reports, business rules, flows, and integrations, so the Operations Lead needed to be informed every time one changed. The notification rules were: Rule Implication for the email Notify only after the change is published The email is generated as the final step, after PublishXml succeeds Send from the user who made the change The sender activity party is the signed-in user Send to whoever currently holds the Operations Lead role The recipient is resolved at runtime, not hard-coded Keep the email traceable The email is set Regarding a Picklist Changes Audit Log record Include full change details The HTML body lists action, time, user, entity, field, option name, value, and old label The picklist change itself is the trigger. Everything that follows in this article is about the email. Why Send Emails from JavaScript? Approach Fit for a user-action trigger Power Automate Runs asynchronously, so the user cannot be told in the same interaction whether the email was sent Classic workflow Record-driven and deprecated in favour of Power Automate for new development Plugin Needs a compiled, registered assembly and must reconstruct context the UI already holds JavaScript + Web API Runs in the same interaction, has full context, and reports success or failure to the user immediately Because the web resource runs inside Dynamics 365, each Web API call executes as the signed-in user. Their security roles still decide whether they can create an email, set its recipients, and send it. Anatomy of an Email in Dataverse Before writing any code, it helps to understand that an email in Dynamics 365 is not a single record with To and From text fields. It is an activity made up of several related pieces. email (activity) ├── subject ├── description → HTML body ├── directioncode → true = outgoing ├── statecode / statuscode │ ├── email_activity_parties (collection) │ ├── participationtypemask = 1 → From │ ├── participationtypemask = 2 → To │ ├── participationtypemask = 3 → CC │ └── participationtypemask = 4 → BCC │ └── partyid → systemuser / contact / account / lead … │ └── regardingobjectid → any activity-enabled table Piece What it does Email record Holds the subject, body, direction, and status Activity parties Separate records linking the email to each sender and recipient Regarding Polymorphic lookup … Continue reading D365 CRM – Generating Emails using JavaScript via user actions for US based Azure & AI services company →

Please find this CloudFronts Product at – CloudFronts PO-BC Integration Module | Microsoft Marketplace Watch the webinar – CloudFronts PO-BC Integration Webinar | YouTube Summary Dynamics 365 Project Operations (PO) holds customers, projects and time. Business Central (BC) holds invoices and payments. When the two are not connected, people copy data by hand, which is slow and causes mistakes. The CloudFronts PO-BC Integration Module is a Dynamics 365 Project Operations and Business Central integration. You set up the link once, and every change in PO shows up in BC automatically. The result is no double typing, fewer mistakes and faster billing. This blog shows how it works, step by step. Table of Contents 1Introduction 2Business Challenge 3Why an Integration Hub? 4Implementation Procedure 5End-to-End Working 6Why This Approach Works 7Real-World Use Cases 8Frequently Asked Questions 9Conclusion Introduction: Why Connect Dynamics 365 Project Operations with Business Central Many project-based businesses use two systems. Project Operations (PO) is where the sales and project teams keep customers, projects and time. Business Central (BC) is where the finance team keeps invoices, payments and money records. Both systems need the same details. A customer made in PO must also exist in BC. A project made in PO must also be there when it is time to send an invoice. Without a link, someone has to copy all of this by hand. Here is the full picture of how work moves from a lead to a payment. The top row is PO and the bottom row is BC. The arrows show where the two systems share data. The full flow from lead to payment, and where PO and BC share data. The Solution: We built an Integration Hub. It is a simple web app where you connect PO and BC, set the rules once, and let the data move on its own. Business Challenge: Manual Data Entry Between PO and BC Think about a normal project business. The sales team makes a customer in PO. The project team makes a project and adds tasks. The finance team then needs the same customer and project in BC to send invoices. These details need to be shared between the two systems: Customers and contacts Projects and tasks Planned work and costs Approved time and expenses Vendor invoices and purchase orders Paid status of invoices When people copy these by hand, many problems come up: Extra effort: The same details are typed in two systems. Mistakes: A wrong phone number or address is easy to type. Details that do not match: The two systems slowly stop agreeing with each other. Late invoices: If data reaches finance late, money comes in late. Hard to grow: More customers and projects mean more copying and checking. The Objective: When something changes in PO, BC should get the change by itself. No one should have to copy anything by hand. Why Use an Integration Hub for PO and BC Integration? The Integration Hub is one place where you create and manage every link between PO and BC. You fill a form, choose what to send, and set simple rules. You do not need to write a lot of code. With the Integration Hub, you can: Set up each link once Choose what data moves, from where, and to where Write simple rules for which detail goes where Test the result before it goes live See all links in one list, with their status and last runs Add new links as your business grows In simple words: Think of the Integration Hub as a control room. From here you decide what data moves, from where, and to where. Implementation Procedure: How to Integrate Project Operations with Business Central Step 1 – Choose the Project On the first screen you pick a project. A project here is a group of links. We use the project named PO-BC, which is for Project Operations and Business Central. Choose the project. We are using PO-BC. Step 2 – See the List of Integrations Inside PO-BC you can see all the links. Each row shows its order number, its status, and its last few runs. You can run, edit or deploy each one from here. To add a new one, click New Integration. The list of integrations. Click New Integration to add one. Step 3 – Fill the New Integration Form A form opens on the right side. Here you tell the platform: Integration Name: A name for this link. For example, Accounts. Integration Type: Master means basic details that rarely change, like customers. Transactional means things that happen often, like invoices. Source System and Source Entity: Where the data starts, and what kind of record it is. Here the system is PO, and the record type is accounts. Target System and Target Entity: Where the data goes, and what kind of record it becomes. Here the system is BC, and the record type is customer. Sequence No.: The order in which links run. Customers must exist first, so this is 1. The new integration form. Use Sync CRM Fields to add any missing fields that BC needs on the PO side. Tip: There is a handy button called Sync CRM Fields. Sometimes BC needs a detail that PO does not have yet. This button creates the missing field in PO for you. Scroll down and add a short description. This helps everyone understand later what the link does. Then click Create Integration. Add a clear description, then click Create Integration. Step 4 – Open the Flow After you create the link, you can open its flow. It is a simple picture with boxes from left to right: Source: the PO data (accounts) Data Mapper: the rules that change the data into the shape BC needs Target: the BC data (customer) Return to Source: an optional step to send data back to PO The flow. The Data Mapper box is where we set the rules. Step 5 – Write the Mapping Rules PO and BC use different names for … Continue reading Dynamics 365 Project Operations and Business Central Integration: Automate Data Sync Without Manual Work →

At a Glance Company profile Infrastructure developer with legal entities in India, Southeast Asia and Europe Challenge Run all entities on one Business Central platform, managed from India, while meeting each country’s tax rules Question asked “Can we use only Indian localisation and handle the other countries’ taxes outside the system?” Options evaluated One production environment (India localisation and external tax) vs two production environments (local localisation) Recommendation Two production environments: one India, one Group (W1 base with a partner localisation) Key takeaway Localisation is an environment-level decision, and the hardest one to reverse after go-live Table of Contents Summary The Situation How Localisation Actually Works in Business Central Online Option 1: One Production Environment with External Tax Calculation Option 2: Two Production Environments with Local Localisation Side-by-Side Comparison The Cost Question Our Recommendation A Checklist Before You Decide Conclusion Frequently Asked Questions Summary Most multi-country ERP conversations start with modules: finance, procurement, projects, consolidation. But for groups operating across several tax jurisdictions, one of the earliest decisions matters more than any module choice. Where will each company live, and which localisation will it use? In Business Central online, that decision is easy to underestimate. It looks like a technical setup detail. In practice, it shapes your invoices, your tax returns, your intercompany design and your audit trail for as long as you run the system. Recently, one of our prospect, an infrastructure developer with entities in India, Southeast Asia and Europe, asked us a direct question: “Our finance team sits in India. Can we run every company on Indian localisation and handle the other countries’ taxes outside the system?” This blog walks through how we evaluated that question and what we recommended. The Situation The prospect was moving off separate accounting systems (a different package for each entity) with manual consolidation. Their requirements were clear: Several legal entities, with a holding entity planned above them. Different functional currencies and financial years. India runs April–March, while the other entities run January–December. Different reporting standards: Ind AS, IFRS and SFRS. Two-level consolidation. One central finance team in India managing all entities. Local tax compliance in each country: GST and e-invoicing in India, VAT in Europe, and GST with mandatory e-invoicing in Southeast Asia once registered. Running everything from India made Indian localisation feel like the natural default. The question was whether that default would hold up for the non-Indian entities. How Localisation Actually Works in Business Central Online Before comparing options, it helps to be clear on three points that often surprise finance teams. 1 Localisation is set per environment, not per company. Every company inside a Business Central online environment uses that environment’s localisation. That covers the tax engine, statutory reports and country-specific fields. You can create a Singapore or Cyprus company inside an India environment, but it will behave like an Indian company. 2 Microsoft doesn’t localise every country. Microsoft provides its own localisation for 21 countries, including India, Australia, New Zealand, the UK, the US and much of Western Europe. Many other markets, including Singapore and Cyprus, are served by partner localisation apps on AppSource, installed on Microsoft’s base version (W1). 3 Localisation is free, but environments aren’t. Microsoft doesn’t charge for localisation itself. A tenant includes one production environment. Every additional production environment needs an add-on subscription. Important Changing a company’s localisation after go-live means migrating it to a new environment, then re-testing and re-validating it. Getting this right at the design stage avoids expensive rework later. Option 1: One Production Environment with External Tax Calculation In this model, every company sits in a single environment on India localisation. Tax for the non-Indian entities is calculated in an external tool, and the amounts are brought into Business Central through an integration. What it involves: Switching off India-specific GST/TDS behaviour for the non-Indian companies. Custom invoice and credit-note layouts without India tax fields. An extension to post externally calculated tax amounts, so document totals match the original invoice. An API integration with the external tax tool, plus middleware and error logging. A custom e-invoicing integration (for example, Peppol / InvoiceNow) when it becomes mandatory. Pros One environment to administer. Simpler intercompany and consolidation, with no cross-environment setup. No additional production environment subscription. No partner localisation apps to license. Cons Tax returns are prepared outside Business Central, so they don’t tie directly to the ledger. More custom code to build, test and maintain through every Microsoft update. Two systems to reconcile every period. E-invoicing depends on an access-point provider supporting a non-standard setup. Higher audit exposure, and costly to reverse later. Option 2: Two Production Environments with Local Localisation In this model, the Indian entity sits in an India environment on Microsoft’s India localisation. All other entities sit in a Group environment on the W1 base, with a partner localisation app where needed and standard VAT configuration for the European entity. Intercompany and consolidation between the two environments use Business Central’s standard cross-environment features. Pros Each country’s tax is calculated and posted in Business Central. Local returns and audit files tie directly to the ledger. Invoices follow each country’s format, with no foreign tax fields. E-invoicing is supported through standard partner apps. Less custom code and lower upgrade risk. The same user licence works across both environments, so central finance in India is unaffected. Cons An additional production environment subscription. Partner localisation app subscriptions. Cross-environment intercompany needs experienced setup and testing. Two environments to administer (updates, sandboxes, permissions). Side-by-Side Comparison Area One Environment (India + external tax) Two Environments (local localisation) Production environments 1 2 Non-Indian tax Calculated outside BC, amounts integrated Calculated in BC Local tax returns Prepared outside BC Generated from BC Invoice compliance Custom layouts Standard local formats E-invoicing Custom integration Partner app Intercompany Same environment (simpler) Cross-environment (standard feature) Custom development Higher Lower Audit and upgrade risk Medium–High Low Reversibility Costly migration later Already correct The Cost Question At first glance, the single-environment option looks cheaper because it avoids the additional environment and the … Continue reading How a Multi-Country Infrastructure Group Evaluated One vs Two Production Environments in Dynamics 365 Business Central →

​ Summary An Australian commercial laundry and linen company already sent its quotes from Dynamics 365, with Approve and Reject buttons in the email. It worked, but the links never expired and could be clicked again and again, so a forwarded or months old email could still change a quote. We made every link single use and valid for 30 days. Customers still answer with one click, and the sales team can now trust the decision they see on the quote. In This Blog Why a reusable approval link is a quiet business risk What the customer sees, from email to confirmation What the sales team sees in Dynamics 365 How we went live without breaking quotes already sent When this approach is the right fit Table of Contents Summary→ Business Challenges→ What We Built→ How It Works→ Going Live Safely→ Impact→ Is This Right for You?→ Conclusion→ FAQ→ Get in Touch→ Business Challenges The quoting process itself was in good shape. Sales built the quote in Dynamics 365, generated the PDF and emailed it with two buttons. The customer clicked Approve or Reject and the answer landed on the quote. Nobody had to chase a reply or retype it. The weak spot was the link behind those buttons. It never changed and never expired, and anyone holding the email could use it. In practice that meant: A customer could approve a quote, then click Reject on the same email weeks later and quietly overwrite the decision. An email forwarded inside the customer’s business could be answered by someone who was never meant to decide. Quotes that had been revised and resent still had live buttons in the older emails. For a business that moves straight from an approved quote to a contract, the decision on the record has to be the real one. Before Links worked forever Any click could change the answer Old emails stayed live after a resend After Each link works once, for 30 days The first decision is final Only the newest email is live What We Built For the customer, almost nothing changed, which was the point. The email looks the same, with the quote attached and the two buttons underneath. There is still no login, no portal and no password to remember. The quote email with the PDF attached and one click Approve and Reject buttons. Captured from a test quote, names changed. One click records the decision and shows a short confirmation. When the quote is approved, the page tells the customer the contract is on its way. The confirmation the customer sees after approving. Captured from a test quote. What changed is everything after that first click. If a button is clicked again, the customer is told the quote is already approved and nothing on the record moves. If the link is older than 30 days, or a newer quote email has replaced it, a clear page asks them to contact their sales representative for a fresh link. Clicking the same link again changes nothing and says so plainly. Captured from a test quote. An expired or replaced link points the customer back to their sales contact. Inside Dynamics 365, the customer.s decision is saved straight onto the quote, along with when the link expires. That decision is what starts the contract process, so it now carries real weight. The test quote in Dynamics 365. The timeline confirms the quote document was sent for review and approval. Names changed. How It Works Everything runs on Dynamics 365 and Power Automate, which the client already had. No new apps and no new licences. Step oneSales sends the quoteFrom the quote, as before Step twoA unique link is issuedOne per email, valid for 30 days Step threeThe customer clicksThe link is checked before anything is saved Step fourDecision saved, link closedAny later click is politely turned away How a quote link moves from sent, to used or expired. Each time a quote is sent, Dynamics 365 stores a new private code and an expiry date on the quote, and that code is built into both buttons. When the customer clicks, the flow compares the code in the link with the one on the quote. Only a match within 30 days is accepted. Once the decision is saved, the code is marked as used, so the same link cannot be accepted again. Worth knowing before you start Resending a quote replaces the link, so customers should always act on the newest email. Agree the expiry period with sales up front: 30 days suited this client’s quoting cycle, but yours may be shorter. And make sure the expired page names someone the customer can actually contact. Going Live Safely The tricky part was not the new links. It was the quotes already sitting in customers’ inboxes, sent under the old process without a private code. Switching them off overnight would have turned a security improvement into a stream of confused customers. So those older emails keep working until each quote receives its first answer, and from then on the same single use rules apply. We built and tested in the client’s test environment first, then went live in production with test quotes sent only to our own team before any customer saw the change. Impact A decision you can trust. The answer on the quote is the customer’s first and final one, so contracts start from solid ground. No extra effort for customers. Still one click, still no login, on any phone or laptop. Old emails retire themselves. Revised quotes no longer leave live buttons behind. No new cost. Built on the Dynamics 365 and Power Automate licences the client already owned. Is This Right for You? There is more than one way to collect a customer’s yes. This is how we usually compare them with clients. This projectOne time email link Customer portal Electronic signature Customer effort One click, no login Sign in, then respond Open, review and sign Extra licences None Portal … Continue reading How an Australian Linen Company Made Quote Approvals Secure with One Time Links in Dynamics 365 →

Summary An Emirates-based marine services firm running Microsoft Dynamics 365 Business Central found that an approved purchase order had disappeared, along with every record of who approved it. We confirmed the order had been deleted rather than archived, showed why Business Central removes approval entries together with the document, and identified the likely approvers from the approval chain. We then explained how a point-in-time restore of Production into a sandbox recovers the actual approval history, set up the change log so future deletions are recorded in full, and recommended controls that stop approved documents from being deleted at all. Table of Contents Introduction Understanding the Issue Deleted or Archived? How We Confirmed It Why the Approval Entries Disappeared Reconstructing the Likely Approvers Recovering the Evidence with a Point-in-Time Restore Making Future Deletions Traceable Preventing Approved Documents from Being Deleted Business Impact Frequently Asked Questions Conclusion Introduction Approval workflows in Microsoft Dynamics 365 Business Central give finance teams confidence that every purchase order was reviewed before it went to a vendor. That confidence depends on one assumption: the approval history will still be there when someone needs it. For an Emirates-based marine services firm we work with, that assumption broke. The finance team went looking for a released purchase order and could not find it. When they checked Approval Entries, there was nothing there either. A few days later, two purchase invoices were deleted as well, and the change log had no record of them. 1 Approved purchase order missing 0 Approval entries left for it 28 Days available to recover the evidence This post walks through how we investigated the issue, what Business Central does behind the scenes when a document is deleted, and the setup that makes every future deletion traceable. The Lesson In Business Central, deleting a document also deletes its approval history. Audit trails have to be set up before they are needed, not after. Understanding the Issue The finance team came to us with three questions. Each needed a clear, evidence-based answer. 01 Was It Deleted or Archived? The order was in Purchase Order Archives, so it looked as if someone had simply archived it by hand. 02 Who Approved It? The order had been released through an approval workflow, but Approval Entries showed nothing for it. 03 Why Was Nothing Logged? The change log had just been switched on, yet the invoices deleted afterwards left no trace in it. Deleted or Archived? How We Confirmed It Archiving and deleting both leave a copy in Purchase Order Archives, so the archive alone does not tell you what happened. The difference is what remains in the live system. Archived Archive Document A copy is saved to Purchase Order Archives, but the original order stays in the Purchase Orders list, together with its approval entries. Deleted Delete The order leaves the Purchase Orders list. If Purchases & Payables Setup is set to archive orders, Business Central saves an archive copy automatically at the moment of deletion. We worked through the possibilities one at a time: How we ruled out each possibility Not in Purchase Orders → No Receipts, Invoices or G/L Entries → Only in Archives → Version No. 1 → Deleted The Version section of the archived order settled it: Version No. 1: only one archived version existed, so the order had never been archived by hand. This version was created when the order was deleted. Archived By: the user ID that deleted the order. Date and Time Archived: the exact moment of deletion. Figure 1: The archive version details show who deleted the order and when. Why the Approval Entries Disappeared Approval entries are linked to the document they belong to. When the document is deleted, Business Central deletes its approval entries too. The archive keeps the order’s header and lines, but not its approval history. To show this to the client with evidence rather than theory, we reproduced it on a copy of Production using an older released order: 1 Released Order We picked a purchase order that had been released through the approval workflow. 2 Approvals Recorded Its Approval Entries showed three approvals from three different approvers. 3 Order Deleted After the order was deleted, Approval Entries showed nothing for it. 4 Archive Copy Remains The order was still available in Purchase Order Archives, without its approvals. Figure 2: Before deletion, the test order carries its full approval history. Figure 3: After deletion, the approval entries are gone, even though an archive copy exists. Key Insight Purchase Order Archives answer what the order looked like. They do not answer who approved it. Once a document is deleted, that question can only be answered from a backup. Reconstructing the Likely Approvers With the approval entries gone, we looked at the next purchase order raised by the same user. Approvals follow the approver chain set up in Approval User Setup, so an order from the same requester with a similar amount follows the same route. Step Role What Happens 1 Requester Raises the purchase order and sends it for approval 2 First approver Next user in the requester’s approver chain 3 Second approver Next user in the chain, based on the approval limits A Reconstruction, Not a Record This identifies the most likely approvers, but it is not proof. It assumes the approval setup has not changed since, and that the deleted order’s amount did not cross a limit that would have added another approver. Recovering the Evidence with a Point-in-Time Restore Business Central Online lets you restore an environment to any point in time within the last 28 days. A Production environment can be restored as a new sandbox, which leaves Production untouched. In that copy, the deleted order still exists with all its approval entries. Steps We Recommended In the Business Central Admin Center, open the Production environment and choose Restore. Pick a point in time a few minutes before the deletion. Convert the archive’s timestamp to the time zone the Admin Center … Continue reading Recovering Lost Approval History After a Purchase Order Deletion in Business Central →

Summary For Emirates Consortium, an Abu Dhabi-based diversified holding company already using Microsoft Dynamics 365 Business Central across multiple legal entities, intercompany accounting is a relevant process area. This article explores how standard intercompany functionality can simplify transactions between related companies. It covers intercompany partner relationships, customer and vendor links, and G/L account and dimension mappings. Using practical scenarios, we walk through a sales invoice raised in one company and received as a purchase invoice in another, as well as journal-based allocation of partial expenses. The walkthrough also shows how the Intercompany Outbox and Inbox support transaction review before posting, and highlights key reconciliation controls and limitations. Table of Contents Introduction The Business Problem The Solution Implementation and Process Walkthrough Limitations and Key Considerations Business Impact Frequently Asked Questions Conclusion Introduction Organizations operating through multiple legal entities often share resources, incur costs centrally, and recharge expenses to the company that actually benefits from them. Although these entities belong to the same business group, each company maintains its own accounting records, receivables, payables, and financial reporting. Emirates Consortium LLC is an Abu Dhabi-based diversified holding company with businesses across the UAE and Maldives. As highlighted in the Emirates Consortium customer success story, CloudFronts deployed Dynamics 365 Business Central across five legal entities to support core business processes. For organizations operating across several companies, intercompany recharges and cost allocation are important areas to assess when looking to reduce duplicate finance work. To explore these capabilities, consider two related companies, Gulf Aquaculture (GA) and Gulf Aquaculture Alliance (GAA). The walkthrough covers two practical routes: an intercompany sales invoice for a formal recharge and an intercompany general journal for direct cost allocation. It explains the setup, accounting impact, and important control points involved in both processes. Route A Intercompany Sales Invoice A formal recharge from GA, received in GAA as a purchase invoice. Route B Intercompany General Journal A direct allocation of part of a cost already recorded in GA. The Business Problem The finance team managed transactions for separate group companies, but some costs, such as consultancy, administration, payroll-related expenditure, and project-related operating expenses, were initially incurred or recorded in GA even when they partly or entirely related to GAA. For example, GA might receive an external vendor invoice for AED 10,000, of which AED 4,000 is attributable to GAA. Without a standard cross-company workflow, staff must determine the chargeable amount, prepare a corresponding transaction in the second company, and verify that the two sets of books agree. 10,000 AED external vendor invoice recorded in GA 4,000 AED attributable to GAA 6,000 AED that remains GA’s own cost Handling this manually created five gaps: 01 Manual Re-Entry Re-entering transactions increased the risk of inconsistent amounts, descriptions, or account classifications between companies. 02 Hidden Costs The receiving company needed visibility into its own project and operating expenses rather than having those costs remain embedded in GA. 03 Limited Control Finance required control over which transactions were sent, accepted, and posted, particularly for higher-value recharges. 04 Different Account Structures The chart of accounts and dimensions needed to translate correctly when the two companies used different codes or reporting structures. 05 Month-End Reconciliation Intercompany balances needed to be traceable and reconcilable at month-end. Business Objective Record the charge once in the initiating company, communicate it through Business Central, and let the receiving company review and post the corresponding entry in its own books. The Solution The proposed approach used standard Business Central intercompany functionality rather than a separate custom integration. Both companies were configured as intercompany partners, with mapped accounts and dimensions to support the exchange of transactions. 1. Establishing the Intercompany Relationship Each participating Business Central company needs its own Intercompany Setup and a unique IC Partner Code. The other company is then added as an intercompany partner with an appropriate transfer method. For a partnership inside the same Business Central environment, direct company-to-company transfer can be used where supported by the configured environment. 2. Connecting Customers and Vendors In GA, GAA is represented by an intercompany customer for billing. In GAA, GA is represented by an intercompany vendor for recording the payable. Assigning the relevant IC Partner Code on the customer and vendor records connects the commercial documents to the receiving company. In GA Customer card GAA as an Intercompany Customer Used to bill GAA. The IC Partner Code links the invoice to GAA. In GAA Vendor card GA as an Intercompany Vendor Used to record the payable to GA. The IC Partner Code links it back to GA. 3. Mapping the Intercompany Chart of Accounts Business Central uses a shared intercompany chart of accounts as the language between companies. Each company maps its own G/L accounts to the intercompany accounts and maps incoming intercompany accounts back to its local G/L accounts. When account numbering differs between companies, these mappings are essential. During the walkthrough, the team reviewed how a sales invoice line could carry an IC Partner Reference so that the receiving company would recognize the appropriate expense account. Account mapping in both directions was especially important: an account existing in one company does not guarantee that the other company can post it. 4. Preserving Dimensions and Project Context Intercompany dimensions can transmit reporting context such as Department, Project, or Cost Centre when corresponding dimension codes and values are set up and mapped. The accounting team should confirm that the receiving company’s dimension values accurately represent the destination project or department. 5. Choosing the Appropriate Transaction Route Business Requirement Recommended Standard Route Formal charge for services or reimbursable costs GA intercompany Sales Invoice → GAA Purchase Invoice Partial allocation of an expense already recorded in GA Intercompany General Journal → corresponding journal in GAA Direct allocation while registering an external vendor invoice Purchase Invoice cost-allocation fields for IC Partner, where applicable and tested Correction of an earlier intercompany charge Appropriate credit memo or reversing journal, reviewed in both companies The following walkthrough focuses on the first two routes: intercompany invoices and intercompany … Continue reading How an Abu Dhabi-Based Diversified Holding Company Simplified Intercompany Transactions in Dynamics 365 Business Central →

Summary Connecting Dynamics 365 Project Operations with Business Central creates a continuous data journey from project planning and execution to financial visibility. Project and task information, planning lines, time, materials, expenses, billable values, and invoices must retain their identity and meaning as they move between systems. This implementation focuses on preserving those relationships so that Budget, Actual, Billable, and Invoiced values remain traceable and meaningful throughout the project lifecycle. The result is an integration that does more than synchronize records: it creates a reliable data story that supports project operations, ERP processes, financial analysis, and decision-making. Table of Contents Why Project Data Needs a Journey The Data Journey Entity-to-Entity Mapping Planning Lines Budget vs. Actual vs. Billable vs. Invoiced Execution and Project Journals From Activity to Invoice The Analytics View Implementation Lessons Conclusion The Project Does Not Live in One System Project Operations is where teams plan and manage project work. Business Central is where the project becomes part of an ERP financial workflow. The interesting part is the space between them. When the same customer, project, task, resource, or transaction crosses that boundary, the integration has to preserve more than a name. It has to preserve relationships and translate the source record into the target system’s business model. The Engineering Question “Did the record sync?” is only the first question. “Does the record still mean the same thing?” is the engineering question. CRM Project Operations Where the Project Is Planned Customer, project, tasks, resources, estimates, time, and project activity are planned and managed here. ERP Business Central Where the Project Becomes Financial Project tasks, planning lines, journals, invoices, and financial visibility form the ERP financial structure. CRM side Figure 1: A Project Operations project with stages, customer, dates, estimates, and project context. ERP side Figure 2: The corresponding project structure in Business Central. A Different Way to Look at the Integration Think of It as a Data Pipeline Source entities become mapped entities, mapped entities become ERP records, and ERP records eventually become transactions and financial metrics. How a record moves between the two systems Project Operations projects · tasks · resources → Mapping Layer identity · transformation → Business Central projects · planning lines 01 Plan Estimates, tasks, resources, and planned quantities describe what the project is expected to consume. 02 Execute Time, materials, and expenses create operational evidence of what happened. 03 Bill Billable value moves toward invoicing, turning project activity into commercial output. Entity-to-Entity Mapping Is Where Meaning Gets Preserved One of the most important parts of a Project Operations to Business Central integration is deciding what a source entity becomes in Business Central. The mapping is effectively a semantic contract. Project Operations Business Central Why It Matters Account (Customer) Customer Customer identity must remain consistent across systems Project msdyn_project Project / Job The project becomes the parent financial structure Project Task msdyn_projecttask Project Task / Job Task Task identity is required for planning and transaction attribution Estimate msdyn_estimateline Job Planning Line Planning becomes a structured Business Central financial planning record Time Entry msdyn_timeentry Project Journal Recorded effort can become project usage Figure 3: Account data flowing into Business Central as a customer, carrying its identity across the boundary. Planning Lines Are the Semantic Bridge Planning lines sit at the point where a project plan starts becoming an ERP financial model. In Business Central, planning lines can represent planned cost, billable value, or both, depending on how they are configured. That makes them especially important when explaining the transition from “what we intend to do” to “what the ERP expects this project to cost or generate.” Quantity How much work, material, or resource usage is expected? Unit Cost / Price What cost or commercial rate is associated with the planned quantity? Total Cost / Price The planning line turns quantity and rates into project-level financial expectations. CRM side Figure 4: The work breakdown structure decomposes project work into manageable tasks. ERP side Figure 5: Resource assignments become structured planning lines in Business Central. The Four Numbers People Confuse Most These values answer different questions. Treating them as interchangeable is one of the fastest ways to misread a project dashboard. 01 Budget: What Did We Expect to Spend? Budget represents planned cost. It is a planning value, not proof that the cost has already occurred. 02 Actual: What Cost Was Recorded? Actual (usage) cost is tied to execution and recorded project usage. A blank actual does not mean the budget disappeared; it means no actual usage has been recorded in that context. 03 Billable: What Value Can Be Charged? Billable represents chargeable project value according to the project’s planning and billing configuration. 04 Invoiced: What Has Actually Been Billed? Invoiced is downstream of billable value. A project can have billable value before the corresponding amount has been invoiced. The Simplest Mental Model Budget → Actual answers the cost question. Billable → Invoiced answers the revenue and billing question. Figure 6: Project budgeting concepts in Project Operations (source: Microsoft Learn). Execution Creates the Evidence Once the project moves from planning into execution, operational records begin to tell the story of what actually happened. Time entries, material usage, and expenses are examples of records that contribute to project actuals and downstream ERP transactions. What feeds the project journal Time hours worked + Materials items consumed + Expenses project spend → Project Journal CRM side Figure 7: Time entries recorded against projects and tasks. ERP side Figure 8: Approved time entries represented in the Business Central project journal. Figure 9: Material usage follows the same project-to-ERP transaction path. Engineering Insight An integration should be traceable backwards. If a number appears in an ERP report, you should be able to explain which transaction produced it and which project and task it belongs to. From Project Activity to Invoice The final part of the journey is commercial. Billable project data eventually feeds invoicing, creating a visible chain from planned work to customer-facing financial output. 01 Project Activity Time, materials, expenses, and … Continue reading From Project Operations to Business Central: Following the Data Behind Project Financials →